In the interest of safety, regulations may require a minimum level of equipment functionality before an aircraft may legally dispatch under the regulation. For example, in the US, Federal Aviation Regulation (FAR) 14 CFR Part 121 requires a Master Minimum Equipment List (MMEL) be satisfied before an aircraft may dispatch (e.g., push back from a gate in preparation for departure). Should one item on the MMEL be inoperative, it would be counter to 14 CFR 121 for a certificate holder to allow the aircraft to dispatch.
Of these items of equipment functionality, some non-critical items may be deferred for later maintenance allowing dispatch of the aircraft without the inoperative item. Other items may be critical to aircraft safety requiring operational status before a legal dispatch. For example, an aircraft may defer to later maintenance a relatively minor item such as a single fuel pump while an item critical to safety such as a flight control computer may be required to be operational before dispatch is approved.
Some critical equipment required for dispatch may include an instance of a software application. For example, some aircraft configurations may require at least three instances of the processor generated Primary Flight Display (PFD) application operating and available before dispatch is authorized. One solution to ensure at least three instances of the PFD are available may include an additional processor devoted to maintaining a redundant copy of the critical instance. This solution however, may add additional unnecessary and undesirable cost, weight, and power requirements to the avionics system.
In some aircraft, due to limitations in Hardware or Processor availability, a minimum number of critical required instances of an application and maximum number of available instances of the application may be equal. This equality allows zero room for error since one failure may lead to a time consuming maintenance action and an unnecessary risk to a timely dispatch.
Many critical systems prohibit the dynamic reallocation of resources. Such systems may require a high level of availability and a scripted and preplanned allocation of processing resources. For example, an aircraft operating under a strict safety rules set may not perform a dynamic reallocation of processing of resources.
One or more schedules with static or fixed execution times for each partition or application can be shown to be deterministically safe via analysis. This may be required as part of a system compliance verification.
While theoretically a similar analysis could be performed for dynamic scheduling algorithms, the complexity of the effort increases rapidly as more resources, applications and alternatives are included in the analysis. Practically speaking it may be cost prohibitive to verify the temporal behavior of critical systems with dynamic reallocation of processing resources.
Traditionally, a reallocation of Processor resources from a non-critical application to a critical application may require a time consuming maintenance effort. This reallocation may traditionally include moving Line Replaceable Units (LRU) and/or Line Replaceable Modules (LRM) from one physical location to another. This hardware reallocation a movement may likely undesirably delay the timely dispatch.
Therefore, a need remains for timely and static allocation of processing resources should one required instance of a critical application become inoperative. This timely allocation may direct Processor resources within the constraints of a regulation of a governing body and within desired MMEL requirements allowing timely dispatch despite failure of a critical item.